Field of the Invention
The present invention relates to a method for changing the software in the memory of an electronic control unit, wherein the memory includes at least one read-only memory with multiple original program routines stored therein that constitute at least a portion of the software and that are processed by at least one processor of the control unit, the memory has at least one working memory for storing volatile data, and the memory also has an overlay memory, from which each memory address can be assigned to a memory address in the read-only memory by an assignment information item, with the result that, when an overlay functionality is activated, instead of processing a program routine instruction at an address in the read-only memory, the processor processes the instruction at an assigned address of the overlay memory.
Description of the Background Art
In the automotive industry, the use of software control and regulation mechanisms allows for a degree of efficiency that could not be accomplished using purely mechanical solutions. Modern automobiles contain a network of electronic control units (ECUs) that each have at least a processor that processes program routines, a working memory, and a read-only memory, the latter of which is usually implemented in the form of a flash memory.
All control units additionally have interfaces by means of which they receive sensor data, operate actuators, and communicate with one another. In keeping with general practice in the software industry, use of existing solutions is popular in ECU programming as well. An already existing control unit, for example an engine control unit for an engine from a previous model, then serves as the basis for development of a new control unit. Individual program routines are then selectively modified or developed from scratch, while the majority of the old code is preserved.
Alternatively, manufacturers often contract with suppliers for fully programmed development control units, and then modify them in accordance with their own specific requirements. In this scenario, the newly developed program routines must be integrated into the executable binary code of the control unit, where they replace, change, or supplement the original program routine in question. This integration process is referred to as bypassing.
Various possibilities exist for implementing a bypass. One very common method is service-based bypassing. A service is a special function located in the control unit's memory. It is called at specific points in the program code, and takes over technical performance of the bypass in that it calls the bypass routine, either in addition to or in place of the original program routine, makes the bypass routine's input quantities available, and ensures that values written by the bypass routine are stored at the correct locations in the control unit memory after the bypass routine has run. Other methods work without service functions. They are based on modification of the binary code. For example, it is possible to make variable accesses in a function inactive by inserting switch logic statements.
As a matter of principle, the code of a bypass routine can be located either on an external system or on the control unit itself. The latter possibility, so-called internal bypassing, needs less additional hardware and is not dependent on the presence of special interfaces.
According to the current conventional art, a development control unit needs to be prepared for execution of a bypass. When a service-based bypass method is used, this means that a call to the service function must be integrated into the binary code of a program routine before and/or after (depending on the method) and/or within the function that is to be replaced. In the ideal case, these service calls would already be implemented at the source code level. In practice, this cannot always be accomplished. For example, the supplier of the control unit may not be willing to do so, or the necessity of bypassing a specific function is not identified until after the control unit has already been completed. In such a case, it is also possible to integrate the calls into the binary code after the fact.
According to the current conventional art, installing the code of a bypass routine requires the flash memory of the control unit to be reloaded each time. This is not only time-consuming (from several tens of seconds to minutes) and interrupts ongoing test series, but it also stresses the flash memory, which is physically capable of withstanding only a limited number of storage operations.
In a typical scenario for service-based internal bypassing according to the conventional art, a special bypass service function is present in the flash in addition to the actual program code. A given program routine f that is prepared for a bypass is expanded by two calls to the service. The user who is installing a bypass routine in the flash enters its memory address in a table. The first call to the service function is located directly before f, for example. The service function receives a table position as an argument. If it finds a memory address there, it calls the bypass function that is located at this address. Otherwise, it remains passive. If it is executed, the bypass routine writes all values it produces into a buffer memory having global variables defined especially for it. After running the bypass routine, the processor jumps back to the actual program. The function f then runs normally, regardless of whether a bypass routine was executed or not.
The execution of f is followed by a second call to the service function. It receives a second table position as an argument, and finds the address of an overwrite function there. This function is matched to the bypass routine and was installed together with it. The overwrite routine reads the buffer memory created by the bypass routine and overwrites the variables written by f.
The information about the variables processed by f comes from the A2L file of the control unit. This is a technical description file that is provided with every development control unit. Among other things, it contains a block that associates the functions running on the control unit with the variables each one reads and writes, as well as a second block that lists the memory addresses of the variables. Knowledge of the source code of f thus is not necessary for creating a bypass routine.